Modules/lvgl-module/source/symbols.c (1)

413-414: Consider reversing the ease_in/ease_out ordering for consistency.

Both lv_anim_path_ease_in and lv_anim_path_ease_out are valid, confirmed LVGL path callbacks. However, ease_out is listed before ease_in — the reverse of the convention used by lv_anim_path_ease_in_out directly above. Minor cosmetic nit.

✨ Proposed reorder

-    DEFINE_MODULE_SYMBOL(lv_anim_path_ease_out),
-    DEFINE_MODULE_SYMBOL(lv_anim_path_ease_in),
+    DEFINE_MODULE_SYMBOL(lv_anim_path_ease_in),
+    DEFINE_MODULE_SYMBOL(lv_anim_path_ease_out),

Tactility/Private/Tactility/app/files/State.h (1)

77-78: pending_paste_dst accessors lack mutex protection unlike sibling clipboard methods.

setClipboard/getClipboard/hasClipboard/clearClipboard all acquire the mutex, but getPendingPasteDst() and setPendingPasteDst() do not, even though they participate in the same cross-callback paste workflow (set in onPastePressed, read in onResult). This is likely safe today because both run on the UI thread, but the inconsistency could bite if the threading model changes. Consider either wrapping these in mutex.withLock for consistency or adding a comment documenting the single-thread assumption.

Tactility/Source/app/files/View.cpp (2)

350-378: showActionsForDirectory and showActionsForFile share nearly identical code.

Both methods now have four identical button creations (Copy, Cut, Rename, Delete). Consider extracting common action buttons into a shared helper, adding file-specific buttons as needed.

---

658-663: Lock acquired on src, but the existence check is against dst — the lock doesn't protect the TOCTOU gap on the destination.

file::getLock(src) guards the source path, while stat(dst.c_str(), &st) checks the destination. Between lock->unlock() (Line 663) and the actual write inside doPaste, another operation could create a file at dst. On a single-user embedded device this is low-risk, but the lock here gives a false sense of safety. Consider either locking dst instead (or additionally), or removing the source lock from this check since it doesn't protect anything meaningful here.

Modules/lvgl-module/source/symbols.c (1)

411-414: Optional: reorder ease_in / ease_out before ease_in_out

The existing lv_anim_path_ease_in_out (line 411) was inserted before ease_in and ease_out, producing a slightly counter-intuitive read order. Consider reordering for consistency:

♻️ Proposed reorder

-    DEFINE_MODULE_SYMBOL(lv_anim_path_ease_in_out),
     DEFINE_MODULE_SYMBOL(lv_anim_path_linear),
+    DEFINE_MODULE_SYMBOL(lv_anim_path_ease_in),
+    DEFINE_MODULE_SYMBOL(lv_anim_path_ease_out),
+    DEFINE_MODULE_SYMBOL(lv_anim_path_ease_in_out),
-    DEFINE_MODULE_SYMBOL(lv_anim_path_ease_in),
-    DEFINE_MODULE_SYMBOL(lv_anim_path_ease_out),

Tactility/Source/app/files/View.cpp (1)

124-143: copyRecursive leaves a partial destination directory on failure.

copyFileContents correctly removes a partial file on error (line 119). But when copyRecursive fails mid-directory traversal, the partially-populated destination directory (and any already-copied children) are not removed. The caller never cleans up the partial tree.

Consider rolling back on failure, e.g.:

♻️ Proposed fix

 static bool copyRecursive(const std::string& src, const std::string& dst) {
     if (file::isDirectory(src)) {
         if (!file::findOrCreateDirectory(dst, 0755)) {
             return false;
         }
         bool success = true;
         file::listDirectory(src, [&](const dirent& entry) {
             if (!success) return;
             if (strcmp(entry.d_name, ".") == 0 || strcmp(entry.d_name, "..") == 0) return;
             auto child_src = file::getChildPath(src, entry.d_name);
             auto child_dst = file::getChildPath(dst, entry.d_name);
             if (!copyRecursive(child_src, child_dst)) {
                 success = false;
             }
         });
+        if (!success) {
+            file::deleteRecursively(dst); // remove partial copy
+        }
         return success;
     } else {
         return copyFileContents(src, dst);
     }
 }

Tactility/Source/app/files/View.cpp (1)

539-544: pendingAction not reset before the "Rename failed" informational dialog — inconsistent with doPaste pattern.

When the destination already exists, alertdialog::start("Rename failed", ...) is shown but pendingAction remains ActionRename. On dismiss, onResult re-enters ActionRename and calls inputdialog::getResult on an alertdialog bundle; if that returns empty string the guard !new_name.empty() saves it — but this is fragile. doPaste consistently calls state->setPendingAction(State::ActionNone) before any informational (non-choice) alert. Apply the same pattern here:

♻️ Proposed fix

             if (stat(rename_to.c_str(), &st) == 0) {
                 LOGGER.warn("Rename: destination already exists: \"{}\"", rename_to);
                 lock->unlock();
+                state->setPendingAction(State::ActionNone);
                 alertdialog::start("Rename failed", "\"" + new_name + "\" already exists.");
                 break;
             }